When providing various forms of network service, such as network access or access to applications etc., there can be situations where a serving entity, e.g. a server, gets overloaded by receiving too many service requests more or less simultaneously. Such overload may also be caused by a so called denial-of-service (DoS) attack where malicious clients intentionally flood the service with a huge number of requests. At the initial request, before security has been established, i.e. before the client is authenticated, it is particularly hard to provide protection against overload attacks.
A mechanism known as “puzzles” is sometimes used for avoiding overload situations. The puzzle aims at causing small computational load on clients, thereby creating a period of idle time for the server from which the clients request service. The client must present a solution to the puzzle before being allowed to proceed. The puzzles are created in a computationally asymmetric fashion: it is easy for the server to create new puzzles, but somewhat difficult for the client to solve them.
FIG. 1 illustrates signaling for avoiding attacks, such as DoS or connection depletion attacks, aimed at exhausting computational resources as well as memory resources of a server S leading to overload. A predominant way to implement puzzles is via a cryptographic hash function, F. A client C sends an access request to the server S (arrow A1). In response, the server S chooses a value x and sends a puzzle y=F(x) to the client C (arrow A2) asking the client C to find x. In other instances, the values x and y may have been pre-determined by the server S. If x and y are random or pseudorandom and m and n bits, respectively, in size, this requires on the order of min(2m, 2n) hash function computations for the client C, whereas it only requires one hash function computation for the server S to verify (arrow A4). Standard hash functions have input/output on the order of n and m=100 bits, which would be infeasible to solve. Therefore, the hash values are usually truncated, in the input and/or in the output. For example, the puzzle or the task could be to find x such F(x)=p∥00 . . . 0 where p is allowed to be “anything”, followed by n zeros. Prior art arrangements thus allow for tuning of the difficulty of puzzles by selecting parameters m and/or n, the difficulty of the puzzle thus being determined only by this parameter selection.
In some instances, the sending and receiving/verifying of puzzles may still create unnecessary overhead, i.e. waste resources in terms of bandwidth and computation processing and thus be inefficient, and improvements in view of preventing and controlling overload situations are needed.